Achieving time synchronization in computer networking is still a challenging task. Different elements of the network, such as PCs, workstations, servers, and devices such as routers and switches, and even VoIP phones today use NTP (Network Time Protocol) to get and set their epoch (time) from network-based NTP servers. NTP provides time accuracy on the order of tens of milliseconds. In most cases, this is sufficient.
In areas such as test and process automation, requirements are more strict, requiring time synchronization between networked devices on the order of sub-microsecond accuracy.
This may be accomplished by using GPS-based solutions. However, even if the cost of GPS-based equipment at each node is acceptable, delivery of GPS signals to each location is often not practical, due to the cost of cabling, or due to the requirement of an antenna with a clear view of the necessary number of GPS satellites. When used, though, GPS can provide time synchronization on the order of 50 nanoseconds.
In test and measurement applications, such as measuring one-way packet delays in networks, accuracy on the order of sub-milliseconds is required. Deploying GPS at various points in a network to perform the required network measurements is economically and practically feasible. When it could be envisioned that a region of a computer network might have a few GPS receivers, it would not be practical to equip all network elements with direct access to GPS accuracy.
In recent years the process automation industry has started deploying the IEEE 1588 standard (IEEE 1588-2002, incorporated herein by reference and referred to as 1588) to perform time synchronization between various devices. Unfortunately, in its current form 1588 is limited to very small networks, typically a LAN segment. IEEE 1588 makes the assumption that delays introduced by network elements are symmetrical and uniform. In order for IEEE 1588 to be deployed across wide area networks (WANs), significant investment is required in IEEE 1588 compliant network elements such as switches, hubs, routers, and the like.
There are two methods known in IEEE 1588 to deal with varying and asymmetrical delays at the network switching and routing elements. These delays occur naturally due to the nature of packet-switched traffic. As packets arrive at ports of a network element such as a router or switch, they must be identified and queued to the proper destination. This process introduces variable delays, particularly if multiple packets are queued for the same destination. One method of reducing these delays is to use a boundary clock, and another is to use a transparent clock.
In examining the boundary clock solution, first consider an IEEE 1588 master clock in device A directly connected to an IEEE 1588 slave clock in device B. IEEE 1588 precision time protocol (PTP) messages pass between A and B, establishing and maintaining B's clock in synchrony with A. Introducing a network element such as a router or switch between A and B introduces additional, varying delays in the propagation of IEEE 1588 messages. With a boundary clock, the network element (usually a switch or a router) runs the IEEE 1588 PTP protocol, and is synchronized to an attached master clock, as an example, device A. The boundary clock in turn acts as a master clock to all attached slaves, as an example, device B. Boundary clocks do not pass IEEE 1588 PTP messages.
The boundary clock solution requires the network element at the MAC/PHY level to redirect IEEE 1588 signals to the built-in boundary clock. If multiple network elements are present in the path between devices A and B, all these network elements must provide boundary clock capabilities.
A transparent clock passes IEEE 1588 messages, but either intercepts and modifies some of these messages to account for delays introduced by the network element, or sends follow-up messages containing IEEE 1588 packet delay information. One implementation of a transparent switch calculates how much time a SYNC packet spends in the network element, and then modifies the timestamp of the associated FOLLOW UP packet to account for this delay; similarly, the switch calculates how much time the DELAY REQ packet spends in the network, and modifies the timestamp of the associated DELAY RES packet. The transparent clock functionality must be built into the network element.
Such solutions become more complex when multiple network elements may intervene between an IEEE 1588 master clock and IEEE 1588 slave clocks.